
body definition
  CVE - polygon definition (only) - can be concave - automatic border by the texture and triangle tesselation, object polygon may contain many points and still the algos for collision detection is great (working linearly)
  Other engines - circle, triangle, box, rectangle, simple polygon definition (f.e. up to a few of vertices, may not be concave, may not contain very thin triangles...)

terrain definition
  terrain can be large in CVE, more static objects doesn't make collision detection slower. the terrain vector border is also automatically 
  optimized, so when there are more static objects on one place, they all have like one border only.
  terrain will contain more features, f.e. friction(slippery) settings, restitution settings, a static object can became dynamic (the big rock will be broken off the terrain with bullets...)

objects penetration 
  It is unavoidable in physics simulations
  CVE is solving penetration and un-penetration algos in a different way than other engines

(multi) constraint solver
  common problem in the constraint solver is high mass ratio of objects (one object in much heavier than the other, 
  constraints between objects must be solved many times in solvers)
  it is usually a bottleneck in the engines, when there are more objects in a pile
  
collision detection
  again different way in CVE than in the other engines
  high speed objects require more position iterations to avoid flying through the objects
  CVE doesn't use position iterations to find these collisions, instead it solves each border point and each border line movement in the simulation space

gravity
  physics engines use low gravity to demonstrate nice behaviour of physics
  higher gravity requires more calculations in physics simulations or it
  produces more errors in dynamics (f.e. more penetration, object flying through object,...)
  higher gravity (or other forces acting on objects, like jets, motors,...) usually require higher frequency of dynamics solver (or more position and velocity iterations)

joints
  again there are several algos to solve joints dynamics, that also may depend on features of joints
  CVE needs more features of joints, now we've got motor, dumping, angular friction, angular spring - these features still need to be updated in CVE, not solved very correctly.
  Constraints on joints are solved very well in CVE, also with high mass ratio of objects.
  Other engines offer more types of joints (prismatic, distance, revolute, pulley, gear joint,....) this we plan to make as features of joint, that can be combined for one joint.

+ breaking of objects
+ plastic deformations (with various settings for material) (we plan elastic deformations, too)
+ particle systems (interacting with objects, can deform objects, too, planning much more features)
+ simple motion blur (planning a little better one in future)
+ robots 
  robot is a class containing more objects jointed together
  robot can contain particle systems, too (usefull for jets, bullets, etc.)
  robot class contains various features that need to be coded inside the core of physics engine
  and will contain much more features for game needs
  i didn't find such a class in physics engines
+ simple ligths (can make good look of the scene, switching on and off the lights (f.e. in caves))
+ determinism - it is working ok so far and we plan to use it for replays, recordings and multiplayer

planning features:
elastic deformations
water
magnets (f.e. useful for explosions)
animations (f.e. useful for rotating cannons)
much more particle system features (motion blur, animated particles, combined particles, ...)
senzors (useful for AI, lifts, ...)
